IBIS Macromodel Task Group Meeting date: 26 November 2013 Members (asterisk for those attending): Agilent: Fangyi Rao Radek Biernacki Altera: David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens * Dan Dvorscak * Curtis Clark Steve Pytel Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Brad Brim Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: * Michael Mirmak Maxim Integrated Products: Mahbubul Bari Hassan Rafat Ron Olisar Mentor Graphics: * John Angulo Zhen Mu Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: * Randy Wolff * Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. James Zhou SiSoft: * Walter Katz Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Mike LaBonte (ML). ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Spreadsheet discussed last week - Walter to contact listed parties to make sure use of their names was okay. - A few names were removed, and the spreadsheet was posted to the work archive. (done) ------------- New Discussion: - ML - I planned on starting with item #5 again (IBIS [Component] changes). - The spreadsheet was posted with very slight adjustments. - Walter has brought it one step further. - I'll pass control to Walter if there are no objections. - Walter - [sharing updated spreadsheet and a new email] - I've made minor reference changes and moved some rows in the spreadsheet. - Major item for this discussion is the new ["AA"] section. - We were talking last week about detail changes to [Component]. - I wanted to go back and say, "What are the shortcomings of IBIS for interconnect?" - 1. Connectors - 2. Cables - 3. Broadband EBD - 4. MCM - 5. Interposers - 6. 3-D Structures - 7. Stacked Memory - 8. RDL - 9. Broadband I/O Package Modeling. -10. Package Power Distribution Network (PDN). -11. Broadband I/O On-Die Modeling. -12. On-Die PDN. -13. Interconnect coupling (cross-talk) between I/O and I/O. -14. Interconnect coupling between I/O and PDN. - I made this list 4 years ago, and started on EMD to solve it. - That got sidetracked because we needed IBIS-ISS. So we did that. - Now I have a proposal for EMD that can handle these. - Now, for historical reasons, we have objections that lead to "Can we do it with [Component]?" - Does anyone object to this list of shortcomings? - Does anyone think there are other interconnect shortcomings? - ML - One Question, do we really want to solve every problem related to interconnect? - Walter - Yes, that is a question. - But first, do we currently agree that an IC vendor has no way of generating a broadband interconnect model an EDA tool can just run? - An IBIS-ISS subcircuit can be created, but not just dropped into the EDA tool. - MM - Clarification question - You're saying "IBIS" generally? - Any spec managed by the organization, or just the IBIS document itself? - Walter - On the top of the document I wrote, "IBIS.org" [entire organization]. - Ambrish - SPICE can solve them, why do we need to know if IBIS can handle them? - Walter - I totally agree that someone can do an IBIS-ISS subset SPICE circuit to represent each of them. - Bob - If that's true then the answer based on the clarification question is yes. - IBIS-ISS and touchstone both do parts of it. - Walter - Can I generate an IBIS [Component] that will do it? - ex. I can do a non-broadband EBD. - ex. For [Component] I can't just generate an IBIS [Component] model. - I can generate subcircuits, but not the whole model. - John - You can do everything except the connections. - MM - Exactly. Bits and pieces and say, "Hey, the tool vendor will figure it out.." - Walter is saying there's nothing where everything is self-contained and connected. - It's not just IBIS.org, it's IBIS.org things tied together in an automated way. - Ambrish - We should do this, but it should not be in the IBIS spec itself. - MM - Clarify - You're okay with having some other specification for that? - Ambrish - Yes. IBIS is for buffers, and was stretched to accommodate package. - Now we don't want to stretch it accommodate cables, connectors, etc. - ML - We didn't mind stretching it for package, but now...? - Walter - The three questions in my email are pertinent. - 1. Does IBIS want to create standards for IC Vendors to deliver interconnect models that satisfy any, some or all of the requirements (shortcomings) listed above? - Michael [Mirmak]'s comments are good clarification of this question. - Meaning, provide models so a tool can tie it all together with simple drop down box. - Ambrish is saying the answer is yes, at least for most items on the list. - If so, I make an observation that we created EMD to do all of these. - That leads to question 2. - 2. Is EMD sufficient by itself or should we do some by enhancing [Component]? - 3. Which things, if any, should be done in IBIS [Component]? - Can we get agreement that we should answer these questions before proceeding? - Comments? - John - I believe this is the right way to organize the discussion. - Features vs. functional implementation. - Walter - Any objections? - Ambrish - I don't understand your interpretation of what I said. - I believe we should not be going to 1, 2, 3, 4, .. in your list and trying to extend IBIS to do it. - Randy - I don't think anyone wants to do this. - John - Is this the right question? I think it is. - Walter - You're saying "not in .ibs". - Ambrish - Yes. - Walter - I don't think anyone wants that. - Ambrish - 7 through 13 is "Yes" in .ibs. - Walter - Do we agree IBIS should have a solution for connectors? - Ambrish - IBIS? - Walter - Meaning the IBIS collection of specs, not just .ibs. - MM - Does anyone really truly desire having the formal IBIS document be overarching? - Is that what anyone wants? [implied "No"]. - If we're just saying these are desirable features and can be included in another document then, sure, the discussion can move right along. - Walter - So email question #1, the answer is yes. - We need a way for IC vendors to do this. - EMD can handle all this. - What portion do we want to do in .ibs? - One comment from Ambrish: 5, 7-13 are "Yes" in .ibs. - Ambrish - Isn't SPICE already able to do all this? - Aren't we discounting the fact that tools can do this if we drop them [models] in? - ML - SPICE is not plug-and-play. Always have data layered on top to organize it. - MM - SPICE is not standard except for IBIS-ISS. - Ambrish - IBIS-ISS and touchstone provide support for standardized models. - MM - Whole portions of the industry are saying that for complicated systems it's the connections between these blocks that are really the problem. - We can't leave that to the user. - If we just say SPICE can do it and it's up to the tool user...[that's insufficient]. - ML - These days, if someone says SPICE I just think IBIS-ISS. - John - Same here. - MM - Need to mention a specific SPICE if you're talking top-level netlist. - ML - Need to specify. Just saying SPICE can do it isn't helpful. - ML - [to Walter] - Since we're going to archive this spreadsheet, could you change IBIS.org to "IBIS family"? - Ambrish - We have touchstone, IBIS, IBIS-ISS, anything else? - MM - EBD, package, ICM - superseded by IBIS-ISS. - ML - By something using IBIS-ISS. I haven't written off ICM completely yet. - ML - So the purpose of adding section "AA" is... - A different view point of what we had in "A"? - Is it sort of a binary decision, in or out of the .ibs file? - Walter - No, it's a pre-cursor. - It's silly to talk about all that stuff in "A" if we haven't decided to do the things in "AA". - I point out that EMD was designed to do all of these things. - I think that if we agree on this list... - And I want to make sure I didn't miss anything. Did I miss anything? - Do we want to do Optical Interconnects? - Ambrish - What about 3D ICs, multi-die, more complicated stuff? - Walter - MCM, interposers, RDL, stacked memory...MCM in general handles all 3D. - Already taken care of, but useful to explicitly say it. - John - EBD models boards, but you could talk more about direct geometry of boards. - Answer may be, "No we don't want to..." but... - ML - I think Optical Interconnect is worth adding. - It has been discussed at IBIS summits, so people are interested in it. - Walter - [adding it as item #15] - Yes, we should have it on the radar. - ML - Probably not in .ibs, but who knows. - ML - Is it correct that all the items in list "A" overlap with all the items in "AA" that say "in .ibs"? - Walter - - There is debate about "stacked memory," but all others seem to be "in .ibs". - If we answer the stacked memory question then we can start matching up the items. - ML - I'm saying it's interesting to look at it from the point of view of all of the "in .ibs" vs. "not in .ibs". - So it looks like we've already started down the path of working on what's "in .ibs". - John - I think .ibs vs. EMD is jumping the gun. - Let's go over the list of enhancements first. - Walter - I'd like to resolve the one contentious issue from last week. - Stacked Memory - John sent out an excellent email. - Gist of the email: - IBIS is traditionally one pin, one buffer (ignoring power pins, just signal pins). - There are a bunch of EDA tools that may rely on that one-to-one assumption. - I answered John privately, but my answer was basically: - "I don't care whether it's associated with 'stacked memory' in a .ibs, or .emd, or .ebd". - SiSoft doesn't care. We'll deal with whatever IBIS chooses to support. - There are other EDA vendors here who have a lot of weight because they will have to support it. - IC vendors may still do it any way they want. - I didn't see any other responses to John's email. - John - I got no other private responses. - Yes, you described the issue fully. - It's not tradition just because we like tradition. - This assumption is hard-coded into many tools. - We can deal with this as well and make these changes. - There are lots of consequences. - We are today already using models that do stacked die with EBD. - Downside for the IC vendor is to release a model with an EBD and a .ibs file. - When we're doing a broadband model we've got to have an accompanying IBIS-ISS subcircuit file as well. So the addition of one more file is not a serious disadvantage. - Since we'll be investing a lot in the EMD side for all the other capabilities, how much work do we invest to deal with breaking this hard coded assumption vs. how much do we invest in the new capability. - Walter - If we choose stacked memory as "not in .ibs" and use EMD and EBD instead... - If that is a decision, all of the things in "A" marked xxx fall into that category. - No joins or splits in the die or the package. - John - In the pads going to the I/O buffers. - Walter - No joins, splits, MCM, stacked,... - We're just going to say that if you have these situations you go to EMD, and now we have to focus on package and on-die modeling. - Randy may object. - Randy - I'm fully in support of everything you just talked about. - Stacked memory in a .ibs file is a book keeping thing. - After listening to what John has been saying, it probably doesn't make sense to come up with two solutions and make EDA vendors write a lot more code. - In the end, I just want a solution customers can use and if the models are in EMD format we can deal with that for stacked memory. - ML - In the same place as MCM. - Randy - Yes, no special case. Same as every other multi-die situation. - Walter - No objections that stacked memory is not included in the .ibs file? - ML - So those "xxx" are proposed "No" now? - John - They go away in the .ibs context. Working on them in EMD context. - Walter - Only thing not resolved... - Note - terminology (signal = I/O, supply = PDN). - Do we need to enhance [Component] to include a list of die pads? - ML - From the list above, it looks like the answer is "yes." - Walter - Not necessarily. - The list above says we will support it, but how? - One way is to say - Yeah, I can have 10 pins of Vdd but I assume at the pads of the die they're all shorted together - maybe different at the buffers. Power distribution within the buffers. - Or, if I were to represent PDN separately on-die and package and merge at the die pads, I could choose to combine on-die and package and just have PDN all the way between the pins and buffers. - Those are two options where you don't need supply die pads. - My gut feeling is that we need this and the enhancement to [Component] is relatively straightforward. - Does anyone say, "No, we should not have a list of pads..."? - John - I think we need that in some form. - We have to look at what [Component] needs to do. - We need to look at what we need to do to avoid the extra layer of indirection of wrapper subcircuits to combine them [on-die and package distribution models]". - Walter - And requirements would be that package and on-die models have to use them [list of pads]. - Any objections to taking the question mark of this item? - Bob - Assumption is we still support one-to-one mapping. - [Pin Mapping] keyword can give the same information. - Walter - [Pin Mapping] is fundamentally flawed. - It associates pins with buffers. It's flawed and has nothing to do with the physics of a PDN. - ML - It sort of leaves out the middle. - MM - It assumes an ideal short. - How much of the original scheme needs to be preserved? - Keep [Pin Mapping] around if people want to use it. - But don't try to accommodate it in the new scheme. - Walter - [noting in item A6 the restriction MM just described] - I think it's a wrap. - Ambrish - I think you could remove Brad as a proponent. - Walter - No, he's okay with it. - I also put him as "opponent" temporarily as a joke because he had mentioned that you could avoid it if you wanted to combine them all [on-die and package]." - ML - Concerning BIRD161, should that be left blank so it doesn't appear to be a vote? - May not want to bring it up right this minute. - May want to wait for Arpad to return. - It seems like having had all these discussions we should have less trouble getting past this one. - MM - I don't care if it gets ditched or accepted. - As long as we're clear about whether existing keywords are expected to work with it. - Walter - An IBIS file with just one Tx and one Rx [ex. seen with some AMI models]: - May or may not have package or on-die models, but isn't a real component. - Adding some switches (like BIRD 161) that tell the tool, "this isn't a real component, it's just a..." - Some tweaking of BIRD 161 might be appropriate. - Walter - I think we've made tremendous progress. - Five minutes left, I just want to review something else, item "B", "RDL". - RDL - added to chip, often added by package vendor. - Common practice is if there's an R included in the interconnect from the RDL it is put in the package model, or it could be put in the on-die model. - I think everyone here said, No. - We don't want to add another section to IBIS to have one for package, and on-die and an RDL layer. - Put it all in the package or on-die model. - Walter - We can review the IBIS syntax I offered for "A6" (supply die pads)? - Walter - I plan on taking a memory chip model we've been using as an example and doing various package and on-die models based on what Randy has done. - ML - BIRD 125, BIRD 145, or EMD? - Walter - I did them in EBD, but now that we're focusing on functionality I'm going to take this simple memory component and generate PDN and I/O package and on-die subcircuits... - I want to go back to item 14 [interconnect coupling between I/O and PDN] because that will complicate those examples. - I'd like to end the meeting by discussing 14. - ML - Wait, you'll create EMD like examples for those things? - Walter - Yes, and BIRD 125 and BIRD 145 proponents can generate examples for those. - John - That's a reasonable way to go ahead. - ML - It would be cool if your examples can be done soon enough to consider C1, C2 [EMD vs. BIRD125 for package models] and D1, D2 [EMD vs. BIRD145 for on-die models]. - Probably too late with the short week. - Walter - I can have them done this week. - ML - They can be generated using EMD-like format. - We'll review them and ask others to generate similar examples using BIRD 125 and BIRD 145. AR: Walter produce new syntax examples using EMD-like format - Walter - One last topic - item 14. - We need to have cross-talk, which is coupling between I/O and I/O. - Do we need to have coupling between the PDN and signaling (I/O)? - We certainly have coupling in the simulation (PDN affects voltage buffer sees). - But do we need coupling in the interconnect model? - Coupling between the PDN and the signal in the interconnect model? - ML - Okay, any final comments before we close this meeting? [none] - Thanks everyone for joining. See you next week. ------------- Next meeting: 3 December 2013 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives